The image pixel accessors computed xpos + ypos*stride in signed 32-bit
arithmetic; frames with width*height > INT32_MAX wrap the offset and the
returned pointer lands far outside the buffer (OOB read/write). Widen
stride/offset math to 64 bits and store validated SPS dimensions in
uint16_t.
Large SPS dimensions with 16-bit bit depth overflow the 32-bit allocation
size in de265_image_get_buffer(); the wrapped ~1 KB allocation is later
written with the full plane size, corrupting the heap.
Missing aggregate bound check on predicted reference picture set entries
allows exceeding the 16-entry array, an out-of-bounds array write in
process_reference_picture_set().
CVE-2026-49337: free orphaned slice header when no active image unit
Origin: upstream, https://github.com/strukturag/libde265/commit/683cb9fa603e35840642f98765ab95cdb71cadf9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g5hj-rf9f-7vxm
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0
Comment: Backport: on 1.0.15 the pre-existing unconditional add_slice_segment_header() call must be removed (upstream moves it into the guarded block); keeping both would double-free every slice header.
Slice headers attached to finished pictures without an active image unit
were retained forever; a crafted NAL sequence can grow memory without
bound during continuous streaming.
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
The image pixel accessors computed xpos + ypos*stride in signed 32-bit
arithmetic; frames with width*height > INT32_MAX wrap the offset and the
returned pointer lands far outside the buffer (OOB read/write). Widen
stride/offset math to 64 bits and store validated SPS dimensions in
uint16_t.
Large SPS dimensions with 16-bit bit depth overflow the 32-bit allocation
size in de265_image_get_buffer(); the wrapped ~1 KB allocation is later
written with the full plane size, corrupting the heap.
Missing aggregate bound check on predicted reference picture set entries
allows exceeding the 16-entry array, an out-of-bounds array write in
process_reference_picture_set().
CVE-2026-49337: free orphaned slice header when no active image unit
Origin: upstream, https://github.com/strukturag/libde265/commit/683cb9fa603e35840642f98765ab95cdb71cadf9
Bug: https://github.com/strukturag/libde265/security/advisories/GHSA-g5hj-rf9f-7vxm
Bug-Debian: https://bugs.debian.org/1140431
Applied-Upstream: 1.1.0
Comment: Backport: on 1.0.15 the pre-existing unconditional add_slice_segment_header() call must be removed (upstream moves it into the guarded block); keeping both would double-free every slice header.
Slice headers attached to finished pictures without an active image unit
were retained forever; a crafted NAL sequence can grow memory without
bound during continuous streaming.
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Joachim Bauch [Tue, 21 Nov 2023 07:59:09 +0000 (08:59 +0100)]
libde265 (1.0.13-1) unstable; urgency=medium
* New upstream version 1.0.13
* Fixes CVE-2023-47471 (Closes: #1056187), CVE-2023-43887.
* Update patches for new upstream version.
* d/control: Upstream switched examples to SDL2 (Closes: #1038097).
* Update symbols for new upstream version.
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Joachim Bauch [Thu, 2 Feb 2023 15:06:20 +0000 (15:06 +0000)]
libde265 (1.0.11-1) unstable; urgency=medium
[ Tobias Frost ]
* Make my patch less noisy.
[ Joachim Bauch ]
* New upstream version 1.0.11
* Unpackaged upstream version 1.0.10 fixes the following CVEs, most caused
by the same underlying issue:
CVE-2020-21594, CVE-2020-21595, CVE-2020-21596, CVE-2020-21597,
CVE-2020-21598, CVE-2020-21599, CVE-2020-21600, CVE-2020-21601,
CVE-2020-21602, CVE-2020-21603, CVE-2020-21604, CVE-2020-21605,
CVE-2020-21606, CVE-2022-1253, CVE-2022-43236, CVE-2022-43237,
CVE-2022-43238, CVE-2022-43239, CVE-2022-43240, CVE-2022-43241,
CVE-2022-43242, CVE-2022-43243, CVE-2022-43244, CVE-2022-43245,
CVE-2022-43248, CVE-2022-43249, CVE-2022-43250, CVE-2022-43252,
CVE-2022-43253, CVE-2022-47655
* Remove patch applied upstream.
* Update patches for new upstream version.
* Remove copyright entry for file no longer present in upstream.
* Update symbols for new upstream version.
* Bump "Standards-Version" to 4.6.2
Tobias Frost [Fri, 13 Jan 2023 11:22:45 +0000 (12:22 +0100)]
[PATCH] Don't update sps if they are only repeated
This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:
> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".
This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)
I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.
Tobias Frost [Mon, 12 Dec 2022 13:33:40 +0000 (14:33 +0100)]
[PATCH] Use the sps from the image
(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.
This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)
The following poc will be stop failing if (only) this
patch is applied:
The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)
Tobias Frost [Sun, 22 Jan 2023 12:19:20 +0000 (12:19 +0000)]
libde265 (1.0.9-1.1) unstable; urgency=medium
* Non-maintainer upload.
* Apply patches to mitigate asan failures:
reject_reference_pics_from_different_sps.patch and
use_sps_from_the_image.patch.
* Combined, this two patches fixes:
- CVE-2022-43243, CVE-2022-43248, CVE-2022-43253 (Closes: #1025816)
- CVE-2022-43235, CVE-2022-43236, CVE-2022-43237, CVE-2022-43238,
CVE-2022-43239, CVE-2022-43240, CVE-2022-43241, CVE-2022-43242,
CVE-2022-43244, CVE-2022-43250, CVE-2022-43252 (Closes: #1027179)
- CVE-2022-47655
* Additional patch recycle_sps_if_possible.patch to avoid over-rejecting
valid video streams due to reject_reference_pics_from_different_sps.patch.
* Modifying past changelog entries to indicate when vulnerabilities were
fixed:
- In 1.0.9-1, in total 11 CVE's. see #1004963 and #1014999
- In 1.0.3-1, 1 CVE, see #1029396
* drop unused Build-Depends: libjpeg-dev, libpng-dev and libxv-dev
(Closes: #981260)
projects / libde265.git / log